Network Management involves managing & monitoring of network devices. The management of the devices includes a module referred as Network Management System (NMS). The Network Management System interacts with an Agent Module running on the respective devices for managing the devices.
With the Proliferation of Network devices, the number of devices to be managed is growing tremendously. The business service working in such a network environment is typically realized based on a set of functionality that is orchestrated across various systems & platforms in the network. It is important to also realize that the network is also gradually changing into a SDN enabled environment. As a result of this, the business service working in such a network environment is realized based on a set of functionality that is orchestrated across both the traditional elements (which does not support SDN) & those elements that support SDN through Open Flow.
Typically, Network Management has been more focused on the monitoring of elements & the significance of recovery actions for business services in the case of problems/faults has been dealt in a manual manner wherein an Administrator tends to login manually across multiple systems & perform the action recovery sequence. Since the functioning of the business services is most important aspect for a Provider offering the service, it is more appropriate to have an automated/programmatic approach to the recovery of business services as opposed to the common practice of employing manual methods. Traditionally SNMP has been leveraged largely for network monitoring & more importantly the GET Operations are typically used to get the data with TRAPS being used for asynchronous notifications.
The SET operation has been typically used to perform configuration changes & set Value of the managed object. Actions resulting out of Traps were invariably performed outside the SNMP based elements OR in some cases by defining the OID as a part of MIB definition. While this approach has been in practice, there is a fundamental challenge in this approach with respect to taking recovery actions for business services for SNMP and Open flow based systems.
In this regard, it may be noted that the prior art solutions based on SNMP does not inherently support/have an ability to handle a managed transaction across multiple elements required for performing recovery actions.
Similarly OF-CONFIG 1.2 which defines the communication standard between an OpenFlow switch and an OpenFlow Configuration Point does not have specific aspects that are required for taking E2E recovery actions. OF-CONFIG 1.2 consists of a network management framework which supports BEEP protocol at the transport layer and supports the data structures based on YANG definition. It may also be noted that the key functionality for this is derived from NETCONF which has been in popular use only for configuration management.
It may be noted that as a part of SDN (Software Defined Network), the separation of data plane & control plane has been envisaged & Openflow happens to be one of the mechanisms defined by the standards body for realizing this separation. In an SDN network supported by Open flow the errors generated due to the packet treatment by the infrastructure elements such as switches and routers are passed onto the SDN Controller through the TCP connection. The Action sets defined for the errors encountered are used for performing various treatment on the flow related to the packet. Hence, all treatment related to Open flow is limited only to the flow control of a packet at the granular level & treatment of packet flow is done based on matching the headers/flow tables. However it is important to realize that in addition to the above, usually operational errors are typically detected/encountered at run time and these are typically rectified by the administrator only through manual intervention.
Besides, a northbound interface of the SDN Controller is currently yet to be standardized by the Openflow workgroup & hence the protocol specifications also currently prevent from E2E recovery initiated from Network management to an SDN Controller.
Further, as various types of network devices are brought under a Network management System, the set of recovery actions required for say restoring a business service or fault spans across multiple platforms, systems & devices. Essentially, restoration involves performing multiple set of recovery actions within/across multiple network devices. Besides, the actions could result in intermediate responses from the devices & hence the mechanism to change a course of action sequence in a dynamic manner in a programmatic way by the Management System is important. Hence there is a need for Management System OR an SDN controller to be able to instruct the recovery actions & correlate the outcome of such recovery action responses performed by various Agents running in the respective platforms/systems/devices.
U.S. patent application Ser. No. 14/485,099 of Tech Mahindra Ltd. discloses a process/method of communication for enabling the Network Management System to initiate, correlate & control the sequence of recovery actions for a given business scenario & dynamically change the recovery action sequence based on the feedback received from the SNMP Agent had been elaborated. However, as Networks move towards adopting SDN, it is important to realize that both SNMP & Openflow are likely to co-exist in the near future as Openflow along with companion protocol OF-CONFIG only specifies a management mechanism for Layer 2/3 devices such as switches/routers.
Since, the recovery of business services & scenarios would involve many types of network elements in addition to the Layer 2/3 switches & Routers, multiple protocols for management of the devices are expected to co-exist. For example SNMP Agents may be running in many devices other than switches & routers. Examples of such elements include a USSD gateway, SMS Gateway, P-CSCF, S-CSCF, I-CSCF etc in a typical IP Multimedia system. Similarly, in a typical streaming solution there would be many elements such as encoder, IPTV middleware, SetTopBox (STB) etc which typically support SNMP agents. It is important to realize that such networks would also have an IP backbone supporting management through Open flow (Separating the Data & Control Plane) & recovery of actions for a business scenario can span across all these diverse devices which effectively mean that Network Management System should be able to support mechanisms for initiating recovery actions to the Open flow supported elements such as Switches & Routers & also support the Traditional network elements supporting SNMP which is not available in the prior art.
Accordingly, there exists a need to provide a system and method for orchestrating dynamic recovery actions for business services across traditional and SDN supporting Openflow protocol.